App Development: Odds and Ends

The Bottom line: I really like Flutter.
It has been extremely challenging at times, but the lessons learned from those challenges have been mostly fundamental and insightful.

My first major challenge with Flutter came in October when I found I could not update multiple Flutter widgets from various ‘reactive’ sources using Flutter’s Provider package.

I got to a point in my app development where I just couldn’t get the code to do what I needed it to do.

Thus began an architectural journey…

Scouring the web, I tried dozens of variations with every aspect of Flutter’s Provider package I could find information on. I came close to succeeding a couple times, but always, always hit a solid road block towards the end of each implementation.

In the end, my entire codebase felt really… procedural (read, cluttered). I felt claustrophobic in my own code, and could not make heads or tails of all the different flows (and I’ve got plenty of Draw.io diagrams to show for it).

Pressing pause on development, I ventured through an insightful Coursera series on Computer and Object Oriented Systems Design. That course helped me to open my views on what other approaches could be out there to help with my architectural woes.

I knew I was still too new to Flutter to try BLoC just yet, and fortunately a search revealed a couple “clean architecture” approaches that were more ‘Provider-like’.

1. The first of the two architectures I ventured to learn was FilledStacks.

Filled Stacks provides in-depth tutorials showing both their clean architecture, as well as a transition into using their own FilledStacks library package. Their package aims to do most of the clean architectural heavy lifting, and helps with boilerplate. The Filled Stacks courses were insightful and informative, and I loved the Clean Architecture approach, but he lost me on TDD.

After deliberating, I resolved that I didn’t want to become reliant on a 3rd party library. With my being so new to Flutter, if something broke in their package, I wouldn’t know that it wasn’t me doing something wrong. A package such as this is highly beneficial to developers who have the years of experience who can simply know when something isn’t working “as expected.”

2. The final architectural approach left to put to the test—Ray Wenderlich.

Coincidentally, it turns out that Ray’s architectural approach is based on the FilledStacks architecture, but it doesn’t rely on the Stacked package library. Upon review, I found the essence of Ray’s architectural structure and tutorial walkthrough insightful, as it is essentially a pragmatic lesson in how to use the get_it package; also used by others such as Reso Coder.

Unfortunately, however, despite it’s insights into the architecture outside of the Stacked package, it didn’t detail any reactiveness as FilledStacks provides.

After further deliberation, I decided to attempt to merge the get_it facets of Rays tutorial with the reactiveness of the FilledStacks architecture. I double checked the licensing on the code for FilledStacks (MIT), and I proceeded to create my own little architectural Frankenstein, which, when done, did not work.

I then applied that skeleton setup to my own app, making all the pertinent adjustments across files, and when done, it also worked!

Since that breakthrough, I continued refactoring the rest of the app to leverage the new reactive architectural design. It was tedious, but I can now diagram my app’s architectural flow without it becoming a game of Twister.

References

• Coursera Object Oriented Design
  https://www.coursera.org/specializations/software-design-architecture
• Filled Stacks
  https://filledstacks.com/post/flutter-and-provider-architecture-using-stacked
• Ray Wenderlich
  https://raywenderlich.com/6373413-state-management-with-provider
• Pilot App: Hungry on Hand – A detailed development history
  https://bitbucket.org/kcommiskey/kdrecall-apps/wiki/History

-Keith | https://keithdc.com